ElastiCache利用者必見！！2019年のアップデートを確認しておこう！#DAT323-R #reinvent

「ElastiCacheのクラスタ概念が覆る…！？」

こんにちは(U・ω・U)
AWS事業部の深澤です。

先ほど「Whatʼs new with Amazon ElastiCache」のセッションに参加してきました。そこで2019年に発表されたアップデートについてまとめられていたので、最新情報を皆さんにお届け致します！2019年ももうすぐ終了なので、2019年にElastiCacheアップデートをおさらいして気持ちよく2020年を迎えましょう。

What's new in 2019

本セッションでは以下のアップデートについて言及していました！

M5タイプとR5タイプの最適化と拡張I/O

• 最大170 TBのメモリ内容量まで拡張可能
• AWS Nitro Systemを採用した専用ハードウェアおよび軽量ハイパーバイザーによるパフォーマンスの向上
• 最大3.1GHz Intel Xeonスケーラブルプロセッサ
• I/Oを強化するため、動的ネットワーク処理を追加

T3ノードのサポート

• エントリーレベルの小規模および中規模のAmazon ElastiCacheワークロードに最適
• T3は、バーストCPU使用を処理する能力を備えており、短時間のベースライントラフィックに対して1秒あたり3倍のリクエストのトラフィックスパイクを処理可能
• RedisおよびMemcachedのT2ノードよりも最大36％優れたベースラインパフォーマンスと価格/パフォーマンス
• T2からT3へのオンラインスケールアップ
• T2と同じく無料利用枠の対象であり、T2と同じ価格

オンラインでのスケールアップ & ダウン（Redisのみ対応）

• 基本的にダウンタイムなしでスケールアップとスケールダウンの両方を行うことができるようになった
• Amazon ElastiCache 5.0.5にも対応
• 自動フェールオーバークラスターを使用している場合、クラスターモードまたは非クラスターモードを使用している場合に限る

リーダーエンドポイント（Redisのみ対応）

• クラスターモードを無効にして使用する（クラスターモード無効化に向けた取り組み）
• 全ての読み取り処理をエンドポイントに集約
• リードレプリカ（ノード）間で接続をバランシングする
  • クライアントからは意識せず、ノードの追加/削除が行える

Redis5.0.5対応 & Memchached 1.5.16

• ElastiCacheのミドルウェアバージョンが上がった。

認証トークンを変更（Redisのみ対応）

• この機能の前は、作成時に認証トークンが一度だけ設定され、変更ができなかった
  • 今回のリリースでトークンのローテーションを許可された
• クライアントを中断せずに認証トークンを変更する2段階のプロセス
• 認証トークンで以前にセットアップされた既存のクラスターに新しいトークンを追加
• 転送中の暗号化が有効なクラスターRedis 5.0.5以降でサポート

顧客管理のマスターキー

• AWS Key Management Service（KMS）の顧客管理CMKを使用した保存時の暗号化
• 暗号化キーを使用してAmazon Simple Storage Service（Amazon S3）に保存されたサービスバックアップを含め、ディスク上のすべてのデータを暗号化
• カスタムマネージドCMKは、AWSアカウントのCMKであり、独自に作成して管理する

名前変更コマンド（Redisのみ対応）

• フルマネージドかつ、ダウンタイムなしで実行される
• 名前の変更は、再起動および置換によって維持される
• Redis 5.0.3以降の対応

セルフサービスメンテナンスアップデート

• 以下のサービスでメンテナンスアップデートが利用可能になったときに通知を受け取ることができる
  • Amazon SNS
  • AWS Personal Health Dashboard
  • Amazon CloudWatch events
  • メール
• アップデートを適用するタイミングを制御できる
• 進行状況をリアルタイムで追跡可能
• 自動フェールオーバー対応クラスターのオンライン更新が可能

最後に

皆さん、いかがでしたでしょうか？？僕は結構見落としが多かったので実りの多いセッションになりました！個人的にはリーダーエンドポイントは押さえておいたほうがいいポイントだと思います。リリースされて結構たちますが、現地でセッションを聞いて、よりクラスターエンドポイントは無くなる方向に傾いていくのではという危機感を個人的に感じました。アプリケーション側の改修が大きくないのであれば、書き込みと読み込みのエンドポイントを分けるというのは負荷分散的にも悪くないですし読み込みの際の可用性がグッと引き上がる構成になると思いますので是非ご検討をいただければと！！

以上、深澤（@shun_quartet）でした！
re:Inventの最新情報をどんどん呟いておりますので良かったら覗いてみてくださいm(_ _)m